An Aspect-Oriented Approach for Supporting Autonomic Reconfiguration of Software Architecture

The increasing complexity of current software systems is encouraging the development of self-managed software architectures, i.e. systems capable of reconfiguring their structure at runtime to fulfil a set of goals. Several approaches have covered different aspects of their development, but some issues remain open, such as the maintainability or the scalability of self-management subsystems. Centralized approaches, like self-adaptive architectures, offer good maintenance properties but do not scale well for large systems. On the contrary, decentralized approaches, like self-organising architectures, offer good scalability but are not maintainable: reconfiguration specifications are spread and often tangled with functional specifications. In order to address these issues, this paper presents an aspect-oriented autonomic reconfiguration approach where: (1) each subsystem is provided with self-management properties so it can evolve itself and the components that it is composed of; (2) self-management concerns are isolated and encapsulated into aspects, thus improving its reuse and maintenance. Povzetek: Predstavljen je pristop s samo-preoblikovanjem programske arhitekture

Soporte a la Evolución Dinámica de Tipos Arquitectónicos

Los sistemas software con una fuerte naturaleza dinámica suponen un reto para la ingeniería del software. Este tipo de sistemas requieren de mecanismos que les permitan modificar tanto estructura como comportamiento en tiempo de ejecución, para adaptarse a las distintas situaciones que puedan presentarse. El área de arquitecturas software, que permite describir la estructura de los sistemas complejos a un alto nivel de abstracción, proporcionados grados de dinamismo para la construcción de sistemas dinámicos, dependiendo de si lo que evoluciona es la configuración de la arquitectura o los tipos que componen dicha arquitectura. El primer tipo de evolución, denominado reconfiguración dinámica, permite a una arquitectura software cambiar su configuración en tiempo de ejecución, creando/destruyendo instancias de elementos arquitectónicos y/o las conexiones entre ellas. El segundo tipo de evolución, que denominamos evolución dinámica de tipos arquitectónicos, permite cambiar completamente la especificación arquitectónica de un sistema dinámicamente, bien introduciendo nuevos tipos arquitectónicos, modificando tipos e instancias en ejecución, o bien introduciendo nuevas conexiones. Este artículo presenta cómo soportar este último grado de dinamismo desde un punto de vista independiente de plataforma. Para ello, se han identificado los diferentes asuntos de interés implicados en el proceso y se han encapsulado en aspectos

A model for tracing variability from features to product-line architectures: a case study in smart grids

In current software systems with highly volatile requirements, traceability plays a key role to maintain the consistency between requirements and code. Traceability between artifacts involved in the development of Software Product Lines (SPL) is still more critical because it is necessary to guarantee that the selection of variants that realize the different SPL products meet the requirements. Current SPL traceability mechanisms trace from variability in features to variations in the configuration of product-line architecture (PLA) in terms of adding and removing components. However, it is not always possible to materialize the variable features of a SPL through adding or removing components, since sometimes they are materialized inside components, i.e. in part of their functionality: a class, a service and/or an interface. Additionally, variations that happen inside components may crosscut several components of architecture. These kinds of variations are still challenging and their traceability is not currently well-supported. Therefore, it is not possible to guarantee that those SPL products with these kinds of variations meet the requirements. This paper presents a solution for tracing variability from features to PLA by taking these kinds of variations into account. This solution is based on models and traceability between models in order to automate SPL configuration by selecting the variants and realizing the product application. The FPLA modeling framework supports this solution which has been deployed in a software factory. Validation has consisted in putting the solution into practice to develop a product line of power metering management applications for Smart Grids

Designing and simulating smart grids

Growing energy demands and the increased use of renewal energies have changed the landscape of power networks leading to new challenges. Smart Grids have emerged to cope with these challenges by facilitating the integration of traditional and renewable energy resources in distributed, open, and self-managed ways. Innovative models are needed to design energy infrastructures that can enable self-management of the power grid. Software architectures smoothly integrate the software that provides self-management to Smart Grids and their hardware infrastructures. We present a framework to design the software architectures of autonomous Smart Grids in an intuitive domain-oriented way and to simulate their execution by automatically generating the code from the designed autonomous smart grid architectures

Tutorial de introducción a EMF y GMF

Tutorial de introducción a EMF y GMF. Definición de Lenguajes Específicos de Dominio (DSL) a través de Modelos Específicos de Dominio (DSMs

Tailoring the Scrum Development Process to Address Agile Product Line Engineering

Software Product Line Engineering (SPLE) is becoming widely used due to the improvement it means when developing software products of the same family. However, SPLE demands long-term investment on a product-line platform that might not be profitable due to rapid changing business settings. Since Agile Software Development (ASD) approaches are being successfully applied in volatile markets, several companies have suggested the idea of integrating SPLE and ASD when a family product has to be developed. Agile Product Line Engineering (APLE) advocates the integration of SPLE and ASD to address their lacks when they are individually applied to software development. A previous literature re-view of experiences and practices on APLE revealed important challenges about how to fully put APLE into practice. Our contribution address several of these challenges by tailoring the agile method Scrum by means of three concepts that we have defined: plastic partial components, working PL-architectures, and reactive reuse

A model-driven engineering process for autonomic sensor-actuator networks

Cyber-Physical Systems (CPS) are the next generation of embedded ICT systems designed to be aware of the physical environment by using sensor-actuator networks to provide users with a wide range of smart applications and services. Many of these smart applications are possible due to the incorporation of autonomic control loops that implement advanced processing and analysis of historical and real-time data measured by sensors; plan actions according to a set of goals or policies; and execute plans through actuators. The complexity of this kind of systems requires mechanisms that can assist the system?s design and development. This paper presents a solution for assisting the design and development of CPS based on Model-Driven Development: MindCPS (doMaIN moDel for CPS) solution. MindCPS solution is based on a model that provides modelling primitives for explicitly specifying the autonomic behaviour of CPS and model transformations for automatically generating part of the CPS code. In addition to the automatic code generation, the MindCPS solution offers the possibility of rapidly configuring and developing the core behaviour of a CPS, even for nonsoftware engineers. The MindCPS solution has been put into practice to deploy a smart metering system in a demonstrator located at the Technical University of Madrid

FPLA: a modeling framework for describing flexible software product line architecture

Nowadays, Software Product Line (SPL) engineering [1] has been widely-adopted in software development due to the significant improvements that has provided, such as reducing cost and time-to-market and providing flexibility to respond to planned changes [2]. SPL takes advantage of common features among the products of a family through the systematic reuse of the core-assets and the effective management of variabilities across the products. SPL features are realized at the architectural level in product-line architecture (PLA) models. Therefore, suitable modeling and specification techniques are required to model variability. In fact, architectural variability modeling has become a challenge for SPLE due to the fact that PLA modeling requires not only modeling variability at the level of the external architecture configuration (see [3,4] literature reviews), but also at the level of internal specification of components [5]. In addition, PLA modeling requires preserving the traceability between features and PLAs. Finally, it is important to take into account that PLA modeling should guide architects in modeling the PLA core assets and variability, and in deriving the customized products. To deal with these needs, we present in this demonstration the FPLA Modeling Framework

Model-to-Code transformation from product-line architecture models to aspectJ

Software Product Line Engineering has significant advantages in family-based software development. The common and variable structure for all products of a family is defined through a Product-Line Architecture (PLA) that consists of a common set of reusable components and connectors which can be configured to build the different products. The design of PLA requires solutions for capturing such configuration (variability). The Flexible-PLA Model is a solution that supports the specification of external variability of the PLA configuration, as well as internal variability of components. However, a complete support for product-line development requires translating architecture specifications into code. This complex task needs automation to avoid human error. Since Model-Driven Development allows automatic code generation from models, this paper presents a solution to automatically generate AspectJ code from Flexible-PLA models previously configured to derive specific products. This solution is supported by a modeling framework and validated in a software factory

A Cost-Benefit analysis model for technical debt management considering uncertainty and time

In the last few years, technical debt has been used as a useful means for making the intrinsic cost of the internal software quality weaknesses visible. This visibility is made possible by quantifying this cost. Specifically, technical debt is expressed in terms of two main concepts: principal and interest. The principal is the cost of eliminating or reducing the impact of a, so called, technical debt item in a software system; whereas the interest is the recurring cost, over a time period, of not eliminating a technical debt item. Previous works about technical debt are mainly focused on estimating principal and interest, and on performing a cost-benefit analysis. This cost-benefit analysis allows one to determine if to remove technical debt is profitable and to prioritize which items incurring in technical debt should be fixed first. Nevertheless, for these previous works technical debt is flat along the time. However the introduction of new factors to estimate technical debt may produce non flat models that allow us to produce more accurate predictions. These factors should be used to estimate principal and interest, and to perform cost-benefit analysis related to technical debt. In this paper, we take a step forward introducing the uncertainty about the interest, and the time frame factors so that it becomes possible to depict a number of possible future scenarios. Estimations obtained without considering the possible evolution of the interest over time may be less accurate as they consider simplistic scenarios without changes